ರಿಯಾಕ್ಟ್ ಫೈಬರ್‌ನ ಪ್ರಿಯಾರಿಟಿ ಲೇನ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಪರಿಣತಿ ಸಾಧಿಸಿ ಸುಗಮ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಅನ್ಲಾಕ್ ಮಾಡಿ. ಕನ್‌ಕರೆಂಟ್ ರೆಂಡರಿಂಗ್, ಶೆಡ್ಯೂಲರ್ ಮತ್ತು startTransition ನಂತಹ ಹೊಸ APIಗಳ ಬಗ್ಗೆ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ.
ರಿಯಾಕ್ಟ್ ಫೈಬರ್ ಪ್ರಿಯಾರಿಟಿ ಲೇನ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್: ರೆಂಡರಿಂಗ್ ನಿಯಂತ್ರಣದ ಒಂದು ಆಳವಾದ ನೋಟ
ವೆಬ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಜಗತ್ತಿನಲ್ಲಿ, ಬಳಕೆದಾರರ ಅನುಭವವು ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿದೆ. ಒಂದು ಕ್ಷಣದ ಫ್ರೀಜ್, ಒಂದು ತೊದಲುವ ಅನಿಮೇಷನ್, ಅಥವಾ ಒಂದು ನಿಧಾನವಾದ ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್ ಸಂತೋಷಗೊಂಡ ಬಳಕೆದಾರ ಮತ್ತು ಹತಾಶಗೊಂಡ ಬಳಕೆದಾರರ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸಬಹುದು. ವರ್ಷಗಳಿಂದ, ಡೆವಲಪರ್‌ಗಳು ಸುಗಮ, ಸ್ಪಂದನಾಶೀಲ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸಲು ಬ್ರೌಸರ್‌ನ ಸಿಂಗಲ್-ಥ್ರೆಡೆಡ್ ಸ್ವಭಾವದೊಂದಿಗೆ ಹೋರಾಡುತ್ತಿದ್ದಾರೆ. ರಿಯಾಕ್ಟ್ 16 ರಲ್ಲಿ ಫೈಬರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಪರಿಚಯದೊಂದಿಗೆ, ಮತ್ತು ರಿಯಾಕ್ಟ್ 18 ರಲ್ಲಿ ಕನ್‌ಕರೆಂಟ್ ಫೀಚರ್‌ಗಳ ಸಂಪೂರ್ಣ ಅನುಷ್ಠಾನದೊಂದಿಗೆ, ಆಟವು ಮೂಲಭೂತವಾಗಿ ಬದಲಾಗಿದೆ. ರಿಯಾಕ್ಟ್ ಕೇವಲ UIಗಳನ್ನು ರೆಂಡರ್ ಮಾಡುವ ಲೈಬ್ರರಿಯಿಂದ, UI ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಶೆಡ್ಯೂಲ್ ಮಾಡುವ ಲೈಬ್ರರಿಯಾಗಿ ವಿಕಸನಗೊಂಡಿದೆ.
ಈ ಆಳವಾದ ನೋಟವು ಈ ವಿಕಾಸದ ಹೃದಯ ಭಾಗವನ್ನು ಪರಿಶೋಧಿಸುತ್ತದೆ: ರಿಯಾಕ್ಟ್ ಫೈಬರ್‌ನ ಪ್ರಿಯಾರಿಟಿ ಲೇನ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್. ರಿಯಾಕ್ಟ್ ಈಗ ಏನನ್ನು ರೆಂಡರ್ ಮಾಡಬೇಕು, ಯಾವುದು ಕಾಯಬಹುದು, ಮತ್ತು ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಫ್ರೀಜ್ ಮಾಡದೆಯೇ ಅನೇಕ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತೇವೆ. ಇದು ಕೇವಲ ಒಂದು ಶೈಕ್ಷಣಿಕ ವ್ಯಾಯಾಮವಲ್ಲ; ಈ ಮೂಲಭೂತ ತತ್ವಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ವೇಗವಾದ, ಚುರುಕಾದ ಮತ್ತು ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ನಿಮಗೆ ಅಧಿಕಾರ ನೀಡುತ್ತದೆ.
ಸ್ಟ್ಯಾಕ್ ರಿಕಾನ್ಸೈಲರ್‌ನಿಂದ ಫೈಬರ್‌ಗೆ: ಪುನರ್ರಚನೆಯ ಹಿಂದಿನ 'ಏಕೆ'
ಫೈಬರ್‌ನ ನಾವೀನ್ಯತೆಯನ್ನು ಶ್ಲಾಘಿಸಲು, ನಾವು ಮೊದಲು ಅದರ ಹಿಂದಿನ ಆವೃತ್ತಿಯಾದ ಸ್ಟ್ಯಾಕ್ ರಿಕಾನ್ಸೈಲರ್‌ನ ಮಿತಿಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ರಿಯಾಕ್ಟ್ 16 ಕ್ಕಿಂತ ಮೊದಲು, ರಿಕಾನ್ಸಿಲಿಯೇಷನ್ ಪ್ರಕ್ರಿಯೆ - ಅಂದರೆ, DOM ನಲ್ಲಿ ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ರಿಯಾಕ್ಟ್ ಒಂದು ಟ್ರೀಯನ್ನು ಇನ್ನೊಂದರೊಂದಿಗೆ ಹೋಲಿಸಲು ಬಳಸುವ ಅಲ್ಗಾರಿದಮ್ - ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ರಿಕರ್ಸಿವ್ ಆಗಿತ್ತು. ಒಂದು ಕಾಂಪೊನೆಂಟ್‌ನ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್ ಆದಾಗ, ರಿಯಾಕ್ಟ್ ಸಂಪೂರ್ಣ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಬದಲಾವಣೆಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ, ಮತ್ತು ಅವುಗಳನ್ನು ಒಂದೇ, ಅಡೆತಡೆಯಿಲ್ಲದ ಅನುಕ್ರಮದಲ್ಲಿ DOM ಗೆ ಅನ್ವಯಿಸುತ್ತಿತ್ತು.
ಸಣ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ, ಇದು ಸರಿಯಾಗಿತ್ತು. ಆದರೆ ಆಳವಾದ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಗಳನ್ನು ಹೊಂದಿರುವ ಸಂಕೀರ್ಣ UIಗಳಿಗೆ, ಈ ಪ್ರಕ್ರಿಯೆಯು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು - ಉದಾಹರಣೆಗೆ, 16 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಸಿಂಗಲ್-ಥ್ರೆಡೆಡ್ ಆಗಿರುವುದರಿಂದ, ದೀರ್ಘಕಾಲದ ರಿಕಾನ್ಸಿಲಿಯೇಷನ್ ಟಾಸ್ಕ್ ಮುಖ್ಯ ಥ್ರೆಡ್ ಅನ್ನು ಬ್ಲಾಕ್ ಮಾಡುತ್ತಿತ್ತು. ಇದರರ್ಥ ಬ್ರೌಸರ್ ಇತರ ನಿರ್ಣಾಯಕ ಕಾರ್ಯಗಳನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತಿರಲಿಲ್ಲ, ಉದಾಹರಣೆಗೆ:
- ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು (ಟೈಪಿಂಗ್ ಅಥವಾ ಕ್ಲಿಕ್ ಮಾಡುವ ಹಾಗೆ).
- ಅನಿಮೇಷನ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು (CSS ಅಥವಾ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್-ಆಧಾರಿತ).
- ಇತರ ಸಮಯ-ಸೂಕ್ಷ್ಮ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು.
ಇದರ ಪರಿಣಾಮವಾಗಿ "ಜ್ಯಾಂಕ್" ಎಂದು ಕರೆಯಲ್ಪಡುವ ಒಂದು ವಿದ್ಯಮಾನ ಉಂಟಾಗುತ್ತಿತ್ತು - ಅಂದರೆ ತೊದಲುವ, ಪ್ರತಿಕ್ರಿಯಿಸದ ಬಳಕೆದಾರ ಅನುಭವ. ಸ್ಟ್ಯಾಕ್ ರಿಕಾನ್ಸೈಲರ್ ಏಕ-ಮಾರ್ಗದ ರೈಲ್ವೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿತ್ತು: ಒಮ್ಮೆ ರೈಲು (ಒಂದು ರೆಂಡರ್ ಅಪ್‌ಡೇಟ್) ತನ್ನ ಪ್ರಯಾಣವನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ, ಅದು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೂ ಓಡಬೇಕಿತ್ತು, ಮತ್ತು ಬೇರೆ ಯಾವುದೇ ರೈಲು ಆ ಮಾರ್ಗವನ್ನು ಬಳಸುವಂತಿರಲಿಲ್ಲ. ಈ ಬ್ಲಾಕಿಂಗ್ ಸ್ವಭಾವವೇ ರಿಯಾಕ್ಟ್‌ನ ಕೋರ್ ಅಲ್ಗಾರಿದಮ್‌ನ ಸಂಪೂರ್ಣ ಪುನರ್ರಚನೆಗೆ ಮುಖ್ಯ ಪ್ರೇರಣೆಯಾಗಿತ್ತು.
ರಿಯಾಕ್ಟ್ ಫೈಬರ್‌ನ ಹಿಂದಿನ ಮುಖ್ಯ ಆಲೋಚನೆಯೆಂದರೆ, ರಿಕಾನ್ಸಿಲಿಯೇಷನ್ ಅನ್ನು ಸಣ್ಣ ಸಣ್ಣ ಕೆಲಸದ ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸಬಹುದಾದ ಒಂದು ಪ್ರಕ್ರಿಯೆಯಾಗಿ ಪುನರ್ಕಲ್ಪಿಸುವುದು. ಒಂದೇ, ಬೃಹತ್ ಕೆಲಸದ ಬದಲು, ರೆಂಡರಿಂಗ್ ಅನ್ನು ನಿಲ್ಲಿಸಬಹುದು, ಪುನರಾರಂಭಿಸಬಹುದು ಮತ್ತು ರದ್ದುಗೊಳಿಸಬಹುದು. ಈ ಸಿಂಕ್ರೊನಸ್‌ನಿಂದ ಅಸಿಂಕ್ರೊನಸ್, ಶೆಡ್ಯೂಲ್ ಮಾಡಬಹುದಾದ ಪ್ರಕ್ರಿಯೆಗೆ ಬದಲಾವಣೆಯು ರಿಯಾಕ್ಟ್ ಅನ್ನು ಬ್ರೌಸರ್‌ನ ಮುಖ್ಯ ಥ್ರೆಡ್‌ಗೆ ನಿಯಂತ್ರಣವನ್ನು ಹಿಂದಿರುಗಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಇದರಿಂದ ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್‌ನಂತಹ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಕಾರ್ಯಗಳು ಎಂದಿಗೂ ಬ್ಲಾಕ್ ಆಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಫೈಬರ್ ಏಕ-ಮಾರ್ಗದ ರೈಲ್ವೆಯನ್ನು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಸಂಚಾರಕ್ಕಾಗಿ ಎಕ್ಸ್‌ಪ್ರೆಸ್ ಲೇನ್‌ಗಳಿರುವ ಬಹು-ಲೇನ್ ಹೆದ್ದಾರಿಯಾಗಿ ಪರಿವರ್ತಿಸಿತು.
'ಫೈಬರ್' ಎಂದರೇನು? ಕನ್‌ಕರೆನ್ಸಿಯ ನಿರ್ಮಾಣದ ಘಟಕ
ಮೂಲಭೂತವಾಗಿ, "ಫೈಬರ್" ಎನ್ನುವುದು ಒಂದು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಆಬ್ಜೆಕ್ಟ್ ಆಗಿದ್ದು, ಅದು ಒಂದು ಕೆಲಸದ ಘಟಕವನ್ನು (unit of work) ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಇದು ಒಂದು ಕಾಂಪೊನೆಂಟ್, ಅದರ ಇನ್‌ಪುಟ್ (props), ಮತ್ತು ಅದರ ಔಟ್‌ಪುಟ್ (children) ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ನೀವು ಫೈಬರ್ ಅನ್ನು ವರ್ಚುವಲ್ ಸ್ಟ್ಯಾಕ್ ಫ್ರೇಮ್ ಎಂದು ಭಾವಿಸಬಹುದು. ಹಳೆಯ ಸ್ಟ್ಯಾಕ್ ರಿಕಾನ್ಸೈಲರ್‌ನಲ್ಲಿ, ಬ್ರೌಸರ್‌ನ ಕಾಲ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ರಿಕರ್ಸಿವ್ ಟ್ರೀ ಟ್ರಾವರ್ಸಲ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಬಳಸಲಾಗುತ್ತಿತ್ತು. ಫೈಬರ್‌ನೊಂದಿಗೆ, ರಿಯಾಕ್ಟ್ ತನ್ನದೇ ಆದ ವರ್ಚುವಲ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಇದನ್ನು ಫೈಬರ್ ನೋಡ್‌ಗಳ ಲಿಂಕ್ಡ್ ಲಿಸ್ಟ್ ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಇದು ರಿಯಾಕ್ಟ್‌ಗೆ ರೆಂಡರಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯ ಮೇಲೆ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ.
ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಯಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಎಲಿಮೆಂಟ್‌ಗೂ ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಫೈಬರ್ ನೋಡ್ ಇರುತ್ತದೆ. ಈ ನೋಡ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಜೋಡಿಸಿ ಫೈಬರ್ ಟ್ರೀಯನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ, ಇದು ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀ ರಚನೆಯನ್ನು ಹೋಲುತ್ತದೆ. ಒಂದು ಫೈಬರ್ ನೋಡ್ ನಿರ್ಣಾಯಕ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಅವುಗಳೆಂದರೆ:
- type and key: ಕಾಂಪೊನೆಂಟ್‌ಗಾಗಿ ಗುರುತಿಸುವಿಕೆಗಳು, ನೀವು ರಿಯಾಕ್ಟ್ ಎಲಿಮೆಂಟ್‌ನಲ್ಲಿ ನೋಡುವಂತೆಯೇ.
- child: ಅದರ ಮೊದಲ ಚೈಲ್ಡ್ ಫೈಬರ್‌ಗೆ ಒಂದು ಪಾಯಿಂಟರ್.
- sibling: ಅದರ ಮುಂದಿನ ಸಿಬ್ಲಿಂಗ್ ಫೈಬರ್‌ಗೆ ಒಂದು ಪಾಯಿಂಟರ್.
- return: ಅದರ ಪೇರೆಂಟ್ ಫೈಬರ್‌ಗೆ ಒಂದು ಪಾಯಿಂಟರ್ (ಕೆಲಸ ಪೂರ್ಣಗೊಂಡ ನಂತರ 'ರಿಟರ್ನ್' ಪಾತ್).
- pendingProps and memoizedProps: ಹಿಂದಿನ ಮತ್ತು ಮುಂದಿನ ರೆಂಡರ್‌ನ ಪ್ರಾಪ್ಸ್‌ಗಳು, ಡಿಫಿಂಗ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
- stateNode: ನಿಜವಾದ DOM ನೋಡ್, ಕ್ಲಾಸ್ ಇನ್‌ಸ್ಟಾನ್ಸ್, ಅಥವಾ ಆಧಾರವಾಗಿರುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಎಲಿಮೆಂಟ್‌ಗೆ ಒಂದು ರೆಫರೆನ್ಸ್.
- effectTag: ಮಾಡಬೇಕಾದ ಕೆಲಸವನ್ನು ವಿವರಿಸುವ ಒಂದು ಬಿಟ್‌ಮಾಸ್ಕ್ (ಉದಾ., Placement, Update, Deletion).
ಈ ರಚನೆಯು ರಿಯಾಕ್ಟ್‌ಗೆ ನೇಟಿವ್ ರಿಕರ್ಷನ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗದೆ ಟ್ರೀಯನ್ನು ಟ್ರಾವರ್ಸ್ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ಒಂದು ಫೈಬರ್‌ನಲ್ಲಿ ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು, ನಿಲ್ಲಿಸಬಹುದು, ಮತ್ತು ನಂತರ ತನ್ನ ಸ್ಥಾನವನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಪುನರಾರಂಭಿಸಬಹುದು. ಕೆಲಸವನ್ನು ನಿಲ್ಲಿಸುವ ಮತ್ತು ಪುನರಾರಂಭಿಸುವ ಈ ಸಾಮರ್ಥ್ಯವು ರಿಯಾಕ್ಟ್‌ನ ಎಲ್ಲಾ ಕನ್‌ಕರೆಂಟ್ ಫೀಚರ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೂಲಭೂತ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ.
ಸಿಸ್ಟಮ್‌ನ ಹೃದಯ: ಶೆಡ್ಯೂಲರ್ ಮತ್ತು ಪ್ರಿಯಾರಿಟಿ ಲೆವೆಲ್‌ಗಳು
ಫೈಬರ್‌ಗಳು ಕೆಲಸದ ಘಟಕಗಳಾಗಿದ್ದರೆ, ಶೆಡ್ಯೂಲರ್ ಯಾವ ಕೆಲಸವನ್ನು ಯಾವಾಗ ಮಾಡಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೆದುಳಾಗಿದೆ. ರಿಯಾಕ್ಟ್ ಸ್ಟೇಟ್ ಬದಲಾವಣೆಯಾದ ತಕ್ಷಣವೇ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಅದು ಅಪ್‌ಡೇಟ್‌ಗೆ ಒಂದು ಪ್ರಿಯಾರಿಟಿ ಲೆವೆಲ್ ಅನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನಿಭಾಯಿಸಲು ಶೆಡ್ಯೂಲರ್‌ಗೆ ಕೇಳುತ್ತದೆ. ನಂತರ ಶೆಡ್ಯೂಲರ್ ಬ್ರೌಸರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿ, ಆ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸಲು ಉತ್ತಮ ಸಮಯವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ, ಇದು ಹೆಚ್ಚು ಮುಖ್ಯವಾದ ಕಾರ್ಯಗಳನ್ನು ಬ್ಲಾಕ್ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಆರಂಭದಲ್ಲಿ, ಈ ಸಿಸ್ಟಮ್ ಪ್ರತ್ಯೇಕ ಪ್ರಿಯಾರಿಟಿ ಲೆವೆಲ್‌ಗಳ ಗುಂಪನ್ನು ಬಳಸುತ್ತಿತ್ತು. ಆಧುನಿಕ ಅನುಷ್ಠಾನ (ಲೇನ್ ಮಾದರಿ) ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾಗಿದ್ದರೂ, ಈ ಪರಿಕಲ್ಪನಾತ್ಮಕ ಮಟ್ಟಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಉತ್ತಮ ಆರಂಭದ ಹಂತವಾಗಿದೆ:
- ImmediatePriority: ಇದು ಅತ್ಯುನ್ನತ ಆದ್ಯತೆಯಾಗಿದ್ದು, ತಕ್ಷಣವೇ ನಡೆಯಬೇಕಾದ ಸಿಂಕ್ರೊನಸ್ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗಾಗಿ ಮೀಸಲಿಡಲಾಗಿದೆ. ಇದಕ್ಕೆ ಒಂದು ಶ್ರೇಷ್ಠ ಉದಾಹರಣೆಯೆಂದರೆ ಕಂಟ್ರೋಲ್ಡ್ ಇನ್‌ಪುಟ್. ಬಳಕೆದಾರರು ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್‌ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದಾಗ, UI ಆ ಬದಲಾವಣೆಯನ್ನು ತಕ್ಷಣವೇ ಪ್ರತಿಬಿಂಬಿಸಬೇಕು. ಅದನ್ನು ಕೆಲವು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಕಾಲ ಮುಂದೂಡಿದರೂ, ಇನ್‌ಪುಟ್ ನಿಧಾನವೆನಿಸುತ್ತದೆ.
- UserBlockingPriority: ಇದು ಬಳಕೆದಾರರ ಪ್ರತ್ಯೇಕ ಸಂವಾದಗಳಿಂದ ಉಂಟಾಗುವ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗಾಗಿ, ಉದಾಹರಣೆಗೆ ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡುವುದು ಅಥವಾ ಸ್ಕ್ರೀನ್ ಟ್ಯಾಪ್ ಮಾಡುವುದು. ಇವು ಬಳಕೆದಾರರಿಗೆ ತಕ್ಷಣವೇ ಅನಿಸಬೇಕು ಆದರೆ ಅಗತ್ಯವಿದ್ದರೆ ಅತಿ ಕಡಿಮೆ ಅವಧಿಗೆ ಮುಂದೂಡಬಹುದು. ಹೆಚ್ಚಿನ ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳು ಈ ಆದ್ಯತೆಯಲ್ಲಿ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತವೆ.
- NormalPriority: ಇದು ಹೆಚ್ಚಿನ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗಾಗಿ ಡೀಫಾಲ್ಟ್ ಆದ್ಯತೆಯಾಗಿದೆ, ಉದಾಹರಣೆಗೆ ಡೇಟಾ ಫೆಚ್‌ಗಳಿಂದ (`useEffect`) ಅಥವಾ ನ್ಯಾವಿಗೇಷನ್‌ನಿಂದ ಬರುವ ಅಪ್‌ಡೇಟ್‌ಗಳು. ಈ ಅಪ್‌ಡೇಟ್‌ಗಳು ತಕ್ಷಣವೇ ಆಗಬೇಕಾಗಿಲ್ಲ, ಮತ್ತು ರಿಯಾಕ್ಟ್ ಅವುಗಳನ್ನು ಬಳಕೆದಾರರ ಸಂವಾದಗಳಿಗೆ ಅಡ್ಡಿಯಾಗದಂತೆ ಶೆಡ್ಯೂಲ್ ಮಾಡಬಹುದು.
- LowPriority: ಇದು ಸಮಯ-ಸೂಕ್ಷ್ಮವಲ್ಲದ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗಾಗಿ, ಉದಾಹರಣೆಗೆ ಆಫ್‌ಸ್ಕ್ರೀನ್ ಕಂಟೆಂಟ್ ರೆಂಡರ್ ಮಾಡುವುದು ಅಥವಾ ಅನಾಲಿಟಿಕ್ಸ್ ಈವೆಂಟ್‌ಗಳು.
- IdlePriority: ಅತ್ಯಂತ ಕಡಿಮೆ ಆದ್ಯತೆ, ಬ್ರೌಸರ್ ಸಂಪೂರ್ಣವಾಗಿ ಐಡಲ್ ಆಗಿದ್ದಾಗ ಮಾತ್ರ ಮಾಡಬಹುದಾದ ಕೆಲಸಕ್ಕಾಗಿ. ಇದನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ನೇರವಾಗಿ ವಿರಳವಾಗಿ ಬಳಸುತ್ತದೆ ಆದರೆ ಲಾಗಿಂಗ್ ಅಥವಾ ಭವಿಷ್ಯದ ಕೆಲಸವನ್ನು ಪೂರ್ವ-ಲೆಕ್ಕಾಚಾರ ಮಾಡುವಂತಹ ವಿಷಯಗಳಿಗಾಗಿ ಆಂತರಿಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.
ರಿಯಾಕ್ಟ್ ಅಪ್‌ಡೇಟ್‌ನ ಸಂದರ್ಭವನ್ನು ಆಧರಿಸಿ ಸರಿಯಾದ ಆದ್ಯತೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, `click` ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ನೊಳಗಿನ ಅಪ್‌ಡೇಟ್ ಅನ್ನು `UserBlockingPriority` ಎಂದು ಶೆಡ್ಯೂಲ್ ಮಾಡಲಾಗುತ್ತದೆ, ಆದರೆ `useEffect` ಒಳಗಿನ ಅಪ್‌ಡೇಟ್ ಸಾಮಾನ್ಯವಾಗಿ `NormalPriority` ಆಗಿರುತ್ತದೆ. ಈ ಬುದ್ಧಿವಂತ, ಸಂದರ್ಭ-ಅರಿವಿನ ಆದ್ಯತೆಯು ರಿಯಾಕ್ಟ್ ಅನ್ನು ಬಾಕ್ಸ್‌ನಿಂದ ಹೊರಗೆ ವೇಗವಾಗಿ ಅನುಭವಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ.
ಲೇನ್ ಥಿಯರಿ: ಆಧುನಿಕ ಪ್ರಿಯಾರಿಟಿ ಮಾದರಿ
ರಿಯಾಕ್ಟ್‌ನ ಕನ್‌ಕರೆಂಟ್ ಫೀಚರ್‌ಗಳು ಹೆಚ್ಚು ಅತ್ಯಾಧುನಿಕವಾದಂತೆ, ಸರಳ ಸಂಖ್ಯಾತ್ಮಕ ಆದ್ಯತೆಯ ವ್ಯವಸ್ಥೆಯು ಅಸಮರ್ಪಕವೆಂದು ಸಾಬೀತಾಯಿತು. ಇದು ವಿವಿಧ ಆದ್ಯತೆಗಳ ಬಹು ಅಪ್‌ಡೇಟ್‌ಗಳು, ಅಡಚಣೆಗಳು ಮತ್ತು ಬ್ಯಾಚಿಂಗ್‌ನಂತಹ ಸಂಕೀರ್ಣ ಸನ್ನಿವೇಶಗಳನ್ನು ಸುಲಲಿತವಾಗಿ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದು **ಲೇನ್ ಮಾದರಿ**ಯ ಅಭಿವೃದ್ಧಿಗೆ ಕಾರಣವಾಯಿತು.
ಒಂದೇ ಆದ್ಯತೆಯ ಸಂಖ್ಯೆಯ ಬದಲು, 31 "ಲೇನ್‌ಗಳ" ಒಂದು ಗುಂಪನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಪ್ರತಿಯೊಂದು ಲೇನ್ ವಿಭಿನ್ನ ಆದ್ಯತೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಇದನ್ನು ಬಿಟ್‌ಮಾಸ್ಕ್ ಆಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ - ಒಂದು 31-ಬಿಟ್ ಇಂಟಿಜರ್, ಅಲ್ಲಿ ಪ್ರತಿಯೊಂದು ಬಿಟ್ ಒಂದು ಲೇನ್‌ಗೆ ಅನುರೂಪವಾಗಿದೆ. ಈ ಬಿಟ್‌ಮಾಸ್ಕ್ ವಿಧಾನವು ಅತ್ಯಂತ ದಕ್ಷವಾಗಿದೆ ಮತ್ತು ಶಕ್ತಿಯುತ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ:
- ಬಹು ಆದ್ಯತೆಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುವುದು: ಒಂದೇ ಬಿಟ್‌ಮಾಸ್ಕ್ ಬಾಕಿ ಇರುವ ಆದ್ಯತೆಗಳ ಗುಂಪನ್ನು ಪ್ರತಿನಿಧಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಒಂದು ಕಾಂಪೊನೆಂಟ್‌ನಲ್ಲಿ `UserBlocking` ಅಪ್‌ಡೇಟ್ ಮತ್ತು `Normal` ಅಪ್‌ಡೇಟ್ ಎರಡೂ ಬಾಕಿ ಇದ್ದರೆ, ಅದರ `lanes` ಪ್ರಾಪರ್ಟಿಯಲ್ಲಿ ಆ ಎರಡೂ ಆದ್ಯತೆಗಳ ಬಿಟ್‌ಗಳು 1 ಕ್ಕೆ ಸೆಟ್ ಆಗಿರುತ್ತವೆ.
- ಅತಿಕ್ರಮಣವನ್ನು ಪರಿಶೀಲಿಸುವುದು: ಬಿಟ್‌ವೈಸ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಎರಡು ಲೇನ್‌ಗಳ ಗುಂಪುಗಳು ಅತಿಕ್ರಮಿಸುತ್ತವೆಯೇ ಅಥವಾ ಒಂದು ಗುಂಪು ಇನ್ನೊಂದರ ಉಪಗುಂಪೇ ಎಂದು ಪರಿಶೀಲಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತವೆ. ಒಳಬರುವ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೆಲಸದೊಂದಿಗೆ ಬ್ಯಾಚ್ ಮಾಡಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
- ಕೆಲಸಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುವುದು: ರಿಯಾಕ್ಟ್ ಬಾಕಿ ಇರುವ ಲೇನ್‌ಗಳ ಗುಂಪಿನಲ್ಲಿ ಅತಿ ಹೆಚ್ಚು ಆದ್ಯತೆಯ ಲೇನ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಗುರುತಿಸಬಹುದು ಮತ್ತು ಕಡಿಮೆ ಆದ್ಯತೆಯ ಕೆಲಸವನ್ನು ಸದ್ಯಕ್ಕೆ ನಿರ್ಲಕ್ಷಿಸಿ, ಕೇವಲ ಅದರ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲು ಆಯ್ಕೆ ಮಾಡಬಹುದು.
ಇದಕ್ಕೆ ಒಂದು ಸಾದೃಶ್ಯವೆಂದರೆ 31 ಲೇನ್‌ಗಳಿರುವ ಈಜುಕೊಳ. ಸ್ಪರ್ಧಾತ್ಮಕ ಈಜುಗಾರನಂತಹ ತುರ್ತು ಅಪ್‌ಡೇಟ್‌ಗೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಲೇನ್ ಸಿಗುತ್ತದೆ ಮತ್ತು ಅದು ಅಡೆತಡೆಯಿಲ್ಲದೆ ಮುಂದುವರಿಯಬಹುದು. ಸಾಂದರ್ಭಿಕ ಈಜುಗಾರರಂತಹ ಹಲವಾರು ತುರ್ತು-ಅಲ್ಲದ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಕಡಿಮೆ ಆದ್ಯತೆಯ ಲೇನ್‌ನಲ್ಲಿ ಒಟ್ಟಿಗೆ ಸೇರಿಸಬಹುದು. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಬ್ಬ ಸ್ಪರ್ಧಾತ್ಮಕ ಈಜುಗಾರ ಬಂದರೆ, ಲೈಫ್‌ಗಾರ್ಡ್‌ಗಳು (ಶೆಡ್ಯೂಲರ್) ಆದ್ಯತೆಯ ಈಜುಗಾರನಿಗೆ ದಾರಿ ಮಾಡಿಕೊಡಲು ಸಾಂದರ್ಭಿಕ ಈಜುಗಾರರನ್ನು ನಿಲ್ಲಿಸಬಹುದು. ಲೇನ್ ಮಾದರಿಯು ಈ ಸಂಕೀರ್ಣ ಸಮನ್ವಯವನ್ನು ನಿರ್ವಹಿಸಲು ರಿಯಾಕ್ಟ್‌ಗೆ ಅತ್ಯಂತ ಸೂಕ್ಷ್ಮ ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ವ್ಯವಸ್ಥೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಎರಡು-ಹಂತದ ರಿಕಾನ್ಸಿಲಿಯೇಷನ್ ಪ್ರಕ್ರಿಯೆ
ರಿಯಾಕ್ಟ್ ಫೈಬರ್‌ನ ಮ್ಯಾಜಿಕ್ ಅದರ ಎರಡು-ಹಂತದ ಕಮಿಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮೂಲಕ ಸಾಕಾರಗೊಳ್ಳುತ್ತದೆ. ಈ ಪ್ರತ್ಯೇಕತೆಯೇ ರೆಂಡರಿಂಗ್ ಅನ್ನು ದೃಶ್ಯ ಅಸಂಗತತೆಗಳಿಗೆ ಕಾರಣವಾಗದಂತೆ ಅಡ್ಡಿಪಡಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಹಂತ 1: ರೆಂಡರ್/ರಿಕಾನ್ಸಿಲಿಯೇಷನ್ ಹಂತ (ಅಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಅಡ್ಡಿಪಡಿಸಬಹುದಾದ)
ಇಲ್ಲಿ ರಿಯಾಕ್ಟ್ ಭಾರೀ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ. ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಯ ಮೂಲದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ರಿಯಾಕ್ಟ್ `workLoop` ನಲ್ಲಿ ಫೈಬರ್ ನೋಡ್‌ಗಳನ್ನು ಟ್ರಾವರ್ಸ್ ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಫೈಬರ್‌ಗೆ, ಅದನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಕರೆಯುತ್ತದೆ, ಹೊಸ ಎಲಿಮೆಂಟ್‌ಗಳನ್ನು ಹಳೆಯ ಫೈಬರ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ಮತ್ತು ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ (ಉದಾ., "ಈ DOM ನೋಡ್ ಅನ್ನು ಸೇರಿಸಿ", "ಈ ಅಟ್ರಿಬ್ಯೂಟ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಿ", "ಈ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ").
ಈ ಹಂತದ ನಿರ್ಣಾಯಕ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ಅದು ಅಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಅಡ್ಡಿಪಡಿಸಬಹುದು. ಕೆಲವು ಫೈಬರ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ನಂತರ, ರಿಯಾಕ್ಟ್ `shouldYield` ಎಂಬ ಆಂತರಿಕ ಫಂಕ್ಷನ್ ಮೂಲಕ ತನಗೆ ನಿಗದಿಪಡಿಸಿದ ಸಮಯದ ಸ್ಲೈಸ್ (ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳು) ಮುಗಿದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಈವೆಂಟ್ ಸಂಭವಿಸಿದ್ದರೆ (ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್‌ನಂತೆ) ಅಥವಾ ಅದರ ಸಮಯ ಮುಗಿದಿದ್ದರೆ, ರಿಯಾಕ್ಟ್ ತನ್ನ ಕೆಲಸವನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ತನ್ನ ಪ್ರಗತಿಯನ್ನು ಫೈಬರ್ ಟ್ರೀಯಲ್ಲಿ ಉಳಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್‌ನ ಮುಖ್ಯ ಥ್ರೆಡ್‌ಗೆ ನಿಯಂತ್ರಣವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಬ್ರೌಸರ್ ಮತ್ತೆ ಮುಕ್ತವಾದಾಗ, ರಿಯಾಕ್ಟ್ ತಾನು ನಿಲ್ಲಿಸಿದ ಸ್ಥಳದಿಂದಲೇ ಪುನರಾರಂಭಿಸಬಹುದು.
ಈ ಸಂಪೂರ್ಣ ಹಂತದಲ್ಲಿ, ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು DOM ಗೆ ಫ್ಲಶ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಬಳಕೆದಾರರು ಹಳೆಯ, ಸ್ಥಿರವಾದ UI ಅನ್ನು ನೋಡುತ್ತಾರೆ. ಇದು ನಿರ್ಣಾಯಕವಾಗಿದೆ - ರಿಯಾಕ್ಟ್ ಹಂತ ಹಂತವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಿದರೆ, ಬಳಕೆದಾರರು ಮುರಿದ, ಅರ್ಧ-ರೆಂಡರ್ ಆದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನೋಡುತ್ತಾರೆ. ಎಲ್ಲಾ ರೂಪಾಂತರಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಕಮಿಟ್ ಹಂತಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುತ್ತದೆ.
ಹಂತ 2: ಕಮಿಟ್ ಹಂತ (ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಅಡ್ಡಿಪಡಿಸಲಾಗದ)
ಒಮ್ಮೆ ಸಂಪೂರ್ಣ ಅಪ್‌ಡೇಟ್ ಆದ ಟ್ರೀಗೆ ರೆಂಡರ್ ಹಂತವು ಅಡೆತಡೆಯಿಲ್ಲದೆ ಪೂರ್ಣಗೊಂಡರೆ, ರಿಯಾಕ್ಟ್ ಕಮಿಟ್ ಹಂತಕ್ಕೆ ಚಲಿಸುತ್ತದೆ. ಈ ಹಂತದಲ್ಲಿ, ಅದು ಸಂಗ್ರಹಿಸಿದ ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ತೆಗೆದುಕೊಂಡು ಅವುಗಳನ್ನು DOM ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ.
ಈ ಹಂತವು ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಅಡ್ಡಿಪಡಿಸಲಾಗದು. DOM ಅನ್ನು ಪರಮಾಣುವಾಗಿ ಅಪ್‌ಡೇಟ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದನ್ನು ಒಂದೇ, ವೇಗದ ಸ್ಫೋಟದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ. ಇದು ಬಳಕೆದಾರರು ಎಂದಿಗೂ ಅಸಂಗತ ಅಥವಾ ಭಾಗಶಃ ಅಪ್‌ಡೇಟ್ ಆದ UI ಅನ್ನು ನೋಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಇದು ರಿಯಾಕ್ಟ್ `componentDidMount` ಮತ್ತು `componentDidUpdate` ನಂತಹ ಲೈಫ್‌ಸೈಕಲ್ ಮೆಥಡ್‌ಗಳನ್ನು, ಹಾಗೆಯೇ `useLayoutEffect` ಹುಕ್ ಅನ್ನು ಚಲಾಯಿಸುವ ಸಮಯವೂ ಆಗಿದೆ. ಇದು ಸಿಂಕ್ರೊನಸ್ ಆಗಿರುವುದರಿಂದ, `useLayoutEffect` ನಲ್ಲಿ ದೀರ್ಘಕಾಲದ ಕೋಡ್ ಅನ್ನು ತಪ್ಪಿಸಬೇಕು કારણકે ಅದು ಪೇಂಟಿಂಗ್ ಅನ್ನು ಬ್ಲಾಕ್ ಮಾಡಬಹುದು.
ಕಮಿಟ್ ಹಂತವು ಪೂರ್ಣಗೊಂಡ ನಂತರ ಮತ್ತು DOM ಅಪ್‌ಡೇಟ್ ಆದ ನಂತರ, ರಿಯಾಕ್ಟ್ `useEffect` ಹುಕ್‌ಗಳನ್ನು ಅಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಚಲಾಯಿಸಲು ಶೆಡ್ಯೂಲ್ ಮಾಡುತ್ತದೆ. ಇದು `useEffect` ಒಳಗಿನ ಯಾವುದೇ ಕೋಡ್ (ಡೇಟಾ ಫೆಚಿಂಗ್‌ನಂತಹ) ಬ್ರೌಸರ್ ಅಪ್‌ಡೇಟ್ ಆದ UI ಅನ್ನು ಸ್ಕ್ರೀನ್‌ಗೆ ಪೇಂಟ್ ಮಾಡುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮಗಳು ಮತ್ತು API ನಿಯಂತ್ರಣ
ಸಿದ್ಧಾಂತವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅದ್ಭುತ, ಆದರೆ ಜಾಗತಿಕ ತಂಡಗಳಲ್ಲಿನ ಡೆವಲಪರ್‌ಗಳು ಈ ಶಕ್ತಿಯುತ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗೆ ಬಳಸಿಕೊಳ್ಳಬಹುದು? ರಿಯಾಕ್ಟ್ 18 ಹಲವಾರು APIಗಳನ್ನು ಪರಿಚಯಿಸಿತು, ಅದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ರೆಂಡರಿಂಗ್ ಆದ್ಯತೆಯ ಮೇಲೆ ನೇರ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ.
ಸ್ವಯಂಚಾಲಿತ ಬ್ಯಾಚಿಂಗ್
ರಿಯಾಕ್ಟ್ 18 ರಲ್ಲಿ, ಎಲ್ಲಾ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಅವು ಎಲ್ಲಿಂದ ಬಂದರೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬ್ಯಾಚ್ ಮಾಡಲಾಗುತ್ತದೆ. ಹಿಂದೆ, ರಿಯಾಕ್ಟ್ ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳೊಳಗಿನ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಬ್ಯಾಚ್ ಮಾಡಲಾಗುತ್ತಿತ್ತು. ಪ್ರಾಮಿಸ್‌ಗಳು, `setTimeout`, ಅಥವಾ ನೇಟಿವ್ ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳೊಳಗಿನ ಅಪ್‌ಡೇಟ್‌ಗಳು ಪ್ರತಿಯೊಂದೂ ಪ್ರತ್ಯೇಕ ಮರು-ರೆಂಡರ್ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತಿದ್ದವು. ಈಗ, ಶೆಡ್ಯೂಲರ್‌ಗೆ ಧನ್ಯವಾದಗಳು, ರಿಯಾಕ್ಟ್ ಒಂದು "ಟಿಕ್" ಕಾಯುತ್ತದೆ ಮತ್ತು ಆ ಟಿಕ್‌ನಲ್ಲಿ ಸಂಭವಿಸುವ ಎಲ್ಲಾ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಒಂದೇ, ಆಪ್ಟಿಮೈಸ್ಡ್ ಮರು-ರೆಂಡರ್ ಆಗಿ ಬ್ಯಾಚ್ ಮಾಡುತ್ತದೆ. ಇದು ಅನಗತ್ಯ ರೆಂಡರ್‌ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
`startTransition` API
ರೆಂಡರಿಂಗ್ ಆದ್ಯತೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಇದು ಬಹುಶಃ ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ API ಆಗಿದೆ. `startTransition` ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ತುರ್ತು-ಅಲ್ಲದ ಅಥವಾ "ಟ್ರಾನ್ಸಿಶನ್" ಎಂದು ಗುರುತಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಒಂದು ಸರ್ಚ್ ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಬಳಕೆದಾರರು ಟೈಪ್ ಮಾಡಿದಾಗ, ಎರಡು ವಿಷಯಗಳು ಆಗಬೇಕು: 1. ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್ ಸ್ವತಃ ಹೊಸ ಅಕ್ಷರವನ್ನು ತೋರಿಸಲು ಅಪ್‌ಡೇಟ್ ಆಗಬೇಕು (ಹೆಚ್ಚಿನ ಆದ್ಯತೆ). 2. ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳ ಪಟ್ಟಿಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ ಮರು-ರೆಂಡರ್ ಮಾಡಬೇಕು, ಇದು ನಿಧಾನವಾದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿರಬಹುದು (ಕಡಿಮೆ ಆದ್ಯತೆ).
`startTransition` ಇಲ್ಲದೆ, ಎರಡೂ ಅಪ್‌ಡೇಟ್‌ಗಳು ಒಂದೇ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿರುತ್ತವೆ, ಮತ್ತು ನಿಧಾನವಾಗಿ ರೆಂಡರ್ ಆಗುವ ಪಟ್ಟಿಯು ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್ ನಿಧಾನವಾಗಲು ಕಾರಣವಾಗಬಹುದು, ಇದು ಕಳಪೆ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಪಟ್ಟಿಯ ಅಪ್‌ಡೇಟ್ ಅನ್ನು `startTransition` ನಲ್ಲಿ ಸುತ್ತುವ ಮೂಲಕ, ನೀವು ರಿಯಾಕ್ಟ್‌ಗೆ ಹೇಳುತ್ತೀರಿ: "ಈ ಅಪ್‌ಡೇಟ್ ನಿರ್ಣಾಯಕವಲ್ಲ. ನೀವು ಹೊಸದನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ ಹಳೆಯ ಪಟ್ಟಿಯನ್ನು ಒಂದು ಕ್ಷಣ ತೋರಿಸುವುದು ಸರಿ. ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್ ಅನ್ನು ಸ್ಪಂದನಾಶೀಲವಾಗಿಸುವುದಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಿ."
ಇಲ್ಲಿದೆ ಒಂದು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆ:
Loading search results...
import { useState, useTransition } from 'react';
function SearchPage() {
const [isPending, startTransition] = useTransition();
const [inputValue, setInputValue] = useState('');
const [searchQuery, setSearchQuery] = useState('');
const handleInputChange = (e) => {
// High-priority update: update the input field immediately
setInputValue(e.target.value);
// Low-priority update: wrap the slow state update in a transition
startTransition(() => {
setSearchQuery(e.target.value);
});
};
return (
ಈ ಕೋಡ್‌ನಲ್ಲಿ, `setInputValue` ಒಂದು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಅಪ್‌ಡೇಟ್ ಆಗಿದೆ, ಇದು ಇನ್‌ಪುಟ್ ಎಂದಿಗೂ ನಿಧಾನವಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. `setSearchQuery`, ಇದು ಸಂಭಾವ್ಯವಾಗಿ ನಿಧಾನವಾದ `SearchResults` ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಮರು-ರೆಂಡರ್ ಮಾಡಲು ಪ್ರಚೋದಿಸುತ್ತದೆ, ಇದನ್ನು ಟ್ರಾನ್ಸಿಶನ್ ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ. ಬಳಕೆದಾರರು ಮತ್ತೆ ಟೈಪ್ ಮಾಡಿದರೆ ರಿಯಾಕ್ಟ್ ಈ ಟ್ರಾನ್ಸಿಶನ್ ಅನ್ನು ಅಡ್ಡಿಪಡಿಸಬಹುದು, ಹಳೆಯ ರೆಂಡರ್ ಕೆಲಸವನ್ನು ಬಿಸಾಡಿ ಹೊಸ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಹೊಸದಾಗಿ ಪ್ರಾರಂಭಿಸಬಹುದು. `useTransition` ಹುಕ್ ಒದಗಿಸಿದ `isPending` ಫ್ಲ್ಯಾಗ್ ಈ ಟ್ರಾನ್ಸಿಶನ್ ಸಮಯದಲ್ಲಿ ಬಳಕೆದಾರರಿಗೆ ಲೋಡಿಂಗ್ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸಲು ಅನುಕೂಲಕರ ಮಾರ್ಗವಾಗಿದೆ.
`useDeferredValue` ಹುಕ್
`useDeferredValue` ಇದೇ ರೀತಿಯ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಲು ಬೇರೆ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಟ್ರೀಯ ತುರ್ತು-ಅಲ್ಲದ ಭಾಗವನ್ನು ಮರು-ರೆಂಡರ್ ಮಾಡುವುದನ್ನು ಮುಂದೂಡಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ಡಿಬೌನ್ಸ್ ಅನ್ನು ಅನ್ವಯಿಸಿದಂತೆ, ಆದರೆ ಹೆಚ್ಚು ಚುರುಕಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ರಿಯಾಕ್ಟ್‌ನ ಶೆಡ್ಯೂಲರ್‌ನೊಂದಿಗೆ ನೇರವಾಗಿ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿದೆ.
ಇದು ಒಂದು ಮೌಲ್ಯವನ್ನು ತೆಗೆದುಕೊಂಡು ಆ ಮೌಲ್ಯದ ಹೊಸ ಪ್ರತಿಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ, ಅದು ರೆಂಡರ್ ಸಮಯದಲ್ಲಿ ಮೂಲಕ್ಕಿಂತ "ಹಿಂದೆ ಉಳಿಯುತ್ತದೆ". ಪ್ರಸ್ತುತ ರೆಂಡರ್ ತುರ್ತು ಅಪ್‌ಡೇಟ್‌ನಿಂದ (ಬಳಕೆದಾರರ ಇನ್‌ಪುಟ್‌ನಂತೆ) ಪ್ರಚೋದಿಸಲ್ಪಟ್ಟಿದ್ದರೆ, ರಿಯಾಕ್ಟ್ ಮೊದಲು ಹಳೆಯ, ಡಿಫರ್ಡ್ ಮೌಲ್ಯದೊಂದಿಗೆ ರೆಂಡರ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಹೊಸ ಮೌಲ್ಯದೊಂದಿಗೆ ಕಡಿಮೆ ಆದ್ಯತೆಯಲ್ಲಿ ಮರು-ರೆಂಡರ್ ಅನ್ನು ಶೆಡ್ಯೂಲ್ ಮಾಡುತ್ತದೆ.
`useDeferredValue` ಬಳಸಿ ಸರ್ಚ್ ಉದಾಹರಣೆಯನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡೋಣ:
import { useState, useDeferredValue } from 'react';
function SearchPage() {
const [query, setQuery] = useState('');
const deferredQuery = useDeferredValue(query);
const handleInputChange = (e) => {
setQuery(e.target.value);
};
return (
ಇಲ್ಲಿ, `input` ಯಾವಾಗಲೂ ಇತ್ತೀಚಿನ `query` ನೊಂದಿಗೆ ಅಪ್-ಟು-ಡೇಟ್ ಆಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, `SearchResults` `deferredQuery` ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ಬಳಕೆದಾರರು ವೇಗವಾಗಿ ಟೈಪ್ ಮಾಡಿದಾಗ, `query` ಪ್ರತಿ ಕೀಸ್ಟ್ರೋಕ್‌ನಲ್ಲಿ ಅಪ್‌ಡೇಟ್ ಆಗುತ್ತದೆ, ಆದರೆ `deferredQuery` ತನ್ನ ಹಿಂದಿನ ಮೌಲ್ಯವನ್ನು ರಿಯಾಕ್ಟ್‌ಗೆ ಬಿಡುವಿನ ಕ್ಷಣ ಸಿಗುವವರೆಗೂ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಇದು ಪಟ್ಟಿಯ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಡಿ-ಪ್ರಿಯಾರಿಟೈಜ್ ಮಾಡುತ್ತದೆ, UI ಅನ್ನು ಸುಗಮವಾಗಿರಿಸುತ್ತದೆ.
ಪ್ರಿಯಾರಿಟಿ ಲೇನ್‌ಗಳನ್ನು ದೃಶ್ಯೀಕರಿಸುವುದು: ಒಂದು ಮಾನಸಿಕ ಮಾದರಿ
ಈ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು ಗಟ್ಟಿಗೊಳಿಸಲು ಒಂದು ಸಂಕೀರ್ಣ ಸನ್ನಿವೇಶವನ್ನು ಪರಿಶೀಲಿಸೋಣ. ಒಂದು ಸಾಮಾಜಿಕ ಮಾಧ್ಯಮ ಫೀಡ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ:
- ಆರಂಭಿಕ ಸ್ಥಿತಿ: ಬಳಕೆದಾರರು ದೀರ್ಘ ಪೋಸ್ಟ್‌ಗಳ ಪಟ್ಟಿಯ ಮೂಲಕ ಸ್ಕ್ರಾಲ್ ಮಾಡುತ್ತಿದ್ದಾರೆ. ಇದು ವೀಕ್ಷಣೆಗೆ ಬರುವ ಹೊಸ ಐಟಂಗಳನ್ನು ರೆಂಡರ್ ಮಾಡಲು `NormalPriority` ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ.
- ಹೆಚ್ಚಿನ-ಆದ್ಯತೆಯ ಅಡಚಣೆ: ಸ್ಕ್ರಾಲ್ ಮಾಡುವಾಗ, ಬಳಕೆದಾರರು ಪೋಸ್ಟ್‌ನ ಕಾಮೆಂಟ್ ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಕಾಮೆಂಟ್ ಟೈಪ್ ಮಾಡಲು ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಈ ಟೈಪಿಂಗ್ ಕ್ರಿಯೆಯು ಇನ್‌ಪುಟ್ ಫೀಲ್ಡ್‌ಗೆ `ImmediatePriority` ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ.
- ಸಮಕಾಲಿಕ ಕಡಿಮೆ-ಆದ್ಯತೆಯ ಕೆಲಸ: ಕಾಮೆಂಟ್ ಬಾಕ್ಸ್ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿದ ಪಠ್ಯದ ಲೈವ್ ಪೂರ್ವವೀಕ್ಷಣೆಯನ್ನು ತೋರಿಸುವ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿರಬಹುದು. ಈ ಪೂರ್ವವೀಕ್ಷಣೆಯನ್ನು ರೆಂಡರ್ ಮಾಡುವುದು ನಿಧಾನವಾಗಬಹುದು. ನಾವು ಪೂರ್ವವೀಕ್ಷಣೆಗಾಗಿ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್ ಅನ್ನು `startTransition` ನಲ್ಲಿ ಸುತ್ತುವ ಮೂಲಕ, ಅದನ್ನು `LowPriority` ಅಪ್‌ಡೇಟ್ ಆಗಿ ಮಾಡಬಹುದು.
- ಹಿನ್ನೆಲೆ ಅಪ್‌ಡೇಟ್: ಏಕಕಾಲದಲ್ಲಿ, ಹೊಸ ಪೋಸ್ಟ್‌ಗಳಿಗಾಗಿ ಹಿನ್ನೆಲೆ `fetch` ಕಾಲ್ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಫೀಡ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ "ಹೊಸ ಪೋಸ್ಟ್‌ಗಳು ಲಭ್ಯವಿದೆ" ಬ್ಯಾನರ್ ಅನ್ನು ಸೇರಿಸಲು ಮತ್ತೊಂದು `NormalPriority` ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ.
ರಿಯಾಕ್ಟ್‌ನ ಶೆಡ್ಯೂಲರ್ ಈ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:
- ರಿಯಾಕ್ಟ್ ತಕ್ಷಣವೇ `NormalPriority` ಸ್ಕ್ರಾಲ್ ರೆಂಡರಿಂಗ್ ಕೆಲಸವನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
- ಇದು `ImmediatePriority` ಇನ್‌ಪುಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ತಕ್ಷಣವೇ ನಿಭಾಯಿಸುತ್ತದೆ. ಬಳಕೆದಾರರ ಟೈಪಿಂಗ್ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಂದನಾಶೀಲವಾಗಿರುತ್ತದೆ.
- ಇದು ಹಿನ್ನೆಲೆಯಲ್ಲಿ `LowPriority` ಕಾಮೆಂಟ್ ಪೂರ್ವವೀಕ್ಷಣೆ ರೆಂಡರ್ ಮೇಲೆ ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
- `fetch` ಕಾಲ್ ರಿಟರ್ನ್ ಆಗುತ್ತದೆ, ಬ್ಯಾನರ್‌ಗಾಗಿ `NormalPriority` ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಶೆಡ್ಯೂಲ್ ಮಾಡುತ್ತದೆ. ಇದು ಕಾಮೆಂಟ್ ಪೂರ್ವವೀಕ್ಷಣೆಗಿಂತ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ರಿಯಾಕ್ಟ್ ಪೂರ್ವವೀಕ್ಷಣೆ ರೆಂಡರಿಂಗ್ ಅನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಬ್ಯಾನರ್ ಅಪ್‌ಡೇಟ್ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅದನ್ನು DOM ಗೆ ಕಮಿಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ನಂತರ ಐಡಲ್ ಸಮಯವಿದ್ದಾಗ ಪೂರ್ವವೀಕ್ಷಣೆ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಪುನರಾರಂಭಿಸುತ್ತದೆ.
- ಎಲ್ಲಾ ಬಳಕೆದಾರರ ಸಂವಾದಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ-ಆದ್ಯತೆಯ ಕಾರ್ಯಗಳು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ರಿಯಾಕ್ಟ್ ಮೂಲ `NormalPriority` ಸ್ಕ್ರಾಲ್ ರೆಂಡರಿಂಗ್ ಕೆಲಸವನ್ನು ಅದು ನಿಲ್ಲಿಸಿದ ಸ್ಥಳದಿಂದ ಪುನರಾರಂಭಿಸುತ್ತದೆ.
ಕೆಲಸದ ಈ ಕ್ರಿಯಾತ್ಮಕ ನಿಲುಗಡೆ, ಆದ್ಯತೆ ನೀಡುವುದು, ಮತ್ತು ಪುನರಾರಂಭಿಸುವುದೇ ಪ್ರಿಯಾರಿಟಿ ಲೇನ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್‌ನ ಸಾರ. ಇದು ಬಳಕೆದಾರರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಗ್ರಹಿಕೆಯನ್ನು ಯಾವಾಗಲೂ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಸಂವಾದಗಳು ಕಡಿಮೆ ನಿರ್ಣಾಯಕ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳಿಂದ ಎಂದಿಗೂ ಬ್ಲಾಕ್ ಆಗುವುದಿಲ್ಲ.
ಜಾಗತಿಕ ಪರಿಣಾಮ: ಕೇವಲ ವೇಗವನ್ನು ಮೀರಿ
ರಿಯಾಕ್ಟ್‌ನ ಕನ್‌ಕರೆಂಟ್ ರೆಂಡರಿಂಗ್ ಮಾದರಿಯ ಪ್ರಯೋಜನಗಳು ಕೇವಲ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವೇಗವಾಗಿ ಅನುಭವಿಸುವಂತೆ ಮಾಡುವುದನ್ನು ಮೀರಿ ವಿಸ್ತರಿಸುತ್ತವೆ. ಅವು ಜಾಗತಿಕ ಬಳಕೆದಾರರ ನೆಲೆಗೆ ಪ್ರಮುಖ ವ್ಯಾಪಾರ ಮತ್ತು ಉತ್ಪನ್ನ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೇಲೆ ಸ್ಪಷ್ಟವಾದ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತವೆ.
- ಪ್ರವೇಶಸಾಧ್ಯತೆ (Accessibility): ಸ್ಪಂದನಾಶೀಲ UI ಒಂದು ಪ್ರವೇಶಸಾಧ್ಯ UI ಆಗಿದೆ. ಒಂದು ಇಂಟರ್ಫೇಸ್ ಫ್ರೀಜ್ ಆದಾಗ, ಅದು ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಗೊಂದಲ ಮತ್ತು ನಿರುಪಯುಕ್ತವಾಗಬಹುದು, ಆದರೆ ಇದು ಸ್ಕ್ರೀನ್ ರೀಡರ್‌ಗಳಂತಹ ಸಹಾಯಕ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಅವಲಂಬಿಸಿರುವವರಿಗೆ ವಿಶೇಷವಾಗಿ ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ, ಇದು ಸಂದರ್ಭವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಅಥವಾ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದು.
- ಬಳಕೆದಾರರ ಧಾರಣ (User Retention): ಸ್ಪರ್ಧಾತ್ಮಕ ಡಿಜಿಟಲ್ ಜಗತ್ತಿನಲ್ಲಿ, ಕಾರ್ಯಕ್ಷಮತೆ ಒಂದು ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ. ನಿಧಾನ, ಜ್ಯಾಂಕಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಬಳಕೆದಾರರ ಹತಾಶೆ, ಹೆಚ್ಚಿನ ಬೌನ್ಸ್ ದರಗಳು, ಮತ್ತು ಕಡಿಮೆ ತೊಡಗಿಸಿಕೊಳ್ಳುವಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ಸುಗಮ ಅನುಭವವು ಆಧುನಿಕ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಪ್ರಮುಖ ನಿರೀಕ್ಷೆಯಾಗಿದೆ.
- ಡೆವಲಪರ್ ಅನುಭವ (Developer Experience): ಈ ಶಕ್ತಿಯುತ ಶೆಡ್ಯೂಲಿಂಗ್ ಪ್ರಿಮಿಟಿವ್‌ಗಳನ್ನು ಲೈಬ್ರರಿಯಲ್ಲಿಯೇ ನಿರ್ಮಿಸುವ ಮೂಲಕ, ರಿಯಾಕ್ಟ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಂಕೀರ್ಣ, ಕಾರ್ಯಕ್ಷಮತೆಯ UIಗಳನ್ನು ಹೆಚ್ಚು ಘೋಷಣಾತ್ಮಕವಾಗಿ ನಿರ್ಮಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಸಂಕೀರ್ಣ ಡಿಬೌನ್ಸಿಂಗ್, ಥ್ರಾಟ್ಲಿಂಗ್, ಅಥವಾ `requestIdleCallback` ತರ್ಕವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಬದಲು, ಡೆವಲಪರ್‌ಗಳು `startTransition` ನಂತಹ APIಗಳನ್ನು ಬಳಸಿ ರಿಯಾಕ್ಟ್‌ಗೆ ತಮ್ಮ ಉದ್ದೇಶವನ್ನು ಸರಳವಾಗಿ ಸಂಕೇತಿಸಬಹುದು, ಇದು ಸ್ವಚ್ಛ, ಹೆಚ್ಚು ನಿರ್ವಹಿಸಬಲ್ಲ ಕೋಡ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಜಾಗತಿಕ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಿಗೆ ಕಾರ್ಯಸಾಧ್ಯವಾದ ಸಲಹೆಗಳು
- ಕನ್‌ಕರೆನ್ಸಿಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ: ನಿಮ್ಮ ತಂಡವು ರಿಯಾಕ್ಟ್ 18 ಅನ್ನು ಬಳಸುತ್ತಿದೆಯೆ ಮತ್ತು ಹೊಸ ಕನ್‌ಕರೆಂಟ್ ಫೀಚರ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಇದೊಂದು ಮಾದರಿ ಬದಲಾವಣೆಯಾಗಿದೆ.
- ಟ್ರಾನ್ಸಿಶನ್‌ಗಳನ್ನು ಗುರುತಿಸಿ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ತುರ್ತು-ಅಲ್ಲದ ಯಾವುದೇ UI ಅಪ್‌ಡೇಟ್‌ಗಳಿಗಾಗಿ ಆಡಿಟ್ ಮಾಡಿ. ಹೆಚ್ಚು ನಿರ್ಣಾಯಕ ಸಂವಾದಗಳನ್ನು ಬ್ಲಾಕ್ ಮಾಡುವುದನ್ನು ತಡೆಯಲು ಸಂಬಂಧಿತ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು `startTransition` ನಲ್ಲಿ ಸುತ್ತಿ.
- ಭಾರೀ ರೆಂಡರ್‌ಗಳನ್ನು ಮುಂದೂಡಿ: ನಿಧಾನವಾಗಿ ರೆಂಡರ್ ಆಗುವ ಮತ್ತು ವೇಗವಾಗಿ ಬದಲಾಗುವ ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿರುವ ಕಾಂಪೊನೆಂಟ್‌ಗಳಿಗಾಗಿ, ಅವುಗಳ ಮರು-ರೆಂಡರಿಂಗ್ ಅನ್ನು ಡಿ-ಪ್ರಿಯಾರಿಟೈಜ್ ಮಾಡಲು ಮತ್ತು ಉಳಿದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚುರುಕಾಗಿಡಲು `useDeferredValue` ಬಳಸಿ.
- ಪ್ರೊಫೈಲ್ ಮತ್ತು ಅಳತೆ ಮಾಡಿ: ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್‌ಗಳು ಹೇಗೆ ರೆಂಡರ್ ಆಗುತ್ತವೆ ಎಂಬುದನ್ನು ದೃಶ್ಯೀಕರಿಸಲು ರಿಯಾಕ್ಟ್ ಡೆವ್‌ಟೂಲ್ಸ್ ಪ್ರೊಫೈಲರ್ ಬಳಸಿ. ಪ್ರೊಫೈಲರ್ ಕನ್‌ಕರೆಂಟ್ ರಿಯಾಕ್ಟ್‌ಗಾಗಿ ಅಪ್‌ಡೇಟ್ ಆಗಿದೆ ಮತ್ತು ಯಾವ ಅಪ್‌ಡೇಟ್‌ಗಳು ಅಡ್ಡಿಪಡಿಸಲ್ಪಡುತ್ತಿವೆ ಮತ್ತು ಯಾವುವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡಚಣೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತಿವೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
- ಶಿಕ್ಷಣ ಮತ್ತು ಪ್ರಚಾರ ನೀಡಿ: ನಿಮ್ಮ ತಂಡದೊಳಗೆ ಈ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಪ್ರೋತ್ಸಾಹಿಸಿ. ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಒಂದು ಸಾಮೂಹಿಕ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ, ಮತ್ತು ರಿಯಾಕ್ಟ್‌ನ ಶೆಡ್ಯೂಲರ್‌ನ ಬಗ್ಗೆ ಹಂಚಿಕೊಂಡ ತಿಳುವಳಿಕೆಯು ಅತ್ಯುತ್ತಮ ಕೋಡ್ ಬರೆಯಲು ನಿರ್ಣಾಯಕವಾಗಿದೆ.
ತೀರ್ಮಾನ
ರಿಯಾಕ್ಟ್ ಫೈಬರ್ ಮತ್ತು ಅದರ ಆದ್ಯತೆ-ಆಧಾರಿತ ಶೆಡ್ಯೂಲರ್ ಫ್ರಂಟ್-ಎಂಡ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳ ವಿಕಾಸದಲ್ಲಿ ಒಂದು ಸ್ಮಾರಕದಂತಹ ಪ್ರಗತಿಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. ನಾವು ಬ್ಲಾಕಿಂಗ್, ಸಿಂಕ್ರೊನಸ್ ರೆಂಡರಿಂಗ್ ಪ್ರಪಂಚದಿಂದ ಸಹಕಾರಿ, ಅಡ್ಡಿಪಡಿಸಬಹುದಾದ ಶೆಡ್ಯೂಲಿಂಗ್‌ನ ಹೊಸ ಮಾದರಿಗೆ ಸಾಗಿದ್ದೇವೆ. ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸಬಲ್ಲ ಫೈಬರ್ ತುಣುಕುಗಳಾಗಿ ವಿಭಜಿಸುವ ಮೂಲಕ ಮತ್ತು ಆ ಕೆಲಸಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಲು ಒಂದು ಅತ್ಯಾಧುನಿಕ ಲೇನ್ ಮಾದರಿಯನ್ನು ಬಳಸುವ ಮೂಲಕ, ರಿಯಾಕ್ಟ್ ಬಳಕೆದಾರ-ಕೇಂದ್ರಿತ ಸಂವಾದಗಳನ್ನು ಯಾವಾಗಲೂ ಮೊದಲು ನಿಭಾಯಿಸಲಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಇದು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವಾಗಲೂ ಸುಗಮ ಮತ್ತು ತತ್‌ಕ್ಷಣದ ಅನುಭವ ನೀಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಡೆವಲಪರ್‌ಗಳಿಗೆ, ಟ್ರಾನ್ಸಿಶನ್‌ಗಳು ಮತ್ತು ಡಿಫರ್ಡ್ ಮೌಲ್ಯಗಳಂತಹ ಪರಿಕಲ್ಪನೆಗಳಲ್ಲಿ ಪರಿಣತಿ ಸಾಧಿಸುವುದು ಇನ್ನು ಮುಂದೆ ಐಚ್ಛಿಕ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಲ - ಇದು ಆಧುನಿಕ, ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಒಂದು ಪ್ರಮುಖ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ. ರಿಯಾಕ್ಟ್‌ನ ಪ್ರಿಯಾರಿಟಿ ಲೇನ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡು ಮತ್ತು ಬಳಸಿಕೊಳ್ಳುವ ಮೂಲಕ, ನೀವು ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗೆ ಉತ್ತಮ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ನೀಡಬಹುದು, ಕೇವಲ ಕ್ರಿಯಾತ್ಮಕವಲ್ಲದ, ಆದರೆ ನಿಜವಾಗಿಯೂ ಬಳಸಲು ಸಂತೋಷಕರವಾದ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು.